High Efficiency Video Coding (HEVC) is a new coding standard that has been developed in recent years. In the High Efficiency Video Coding (HEVC) system, the fixed-size macroblock of H.264/AVC is replaced by a flexible block, named coding unit (CU). Pixels in the CU share the same coding parameters to improve coding efficiency. A CU may begin with a largest CU (LCU), which is also referred as coded tree unit (CTU) in HEVC. In addition to the concept of coding unit, the concept of prediction unit (PU) is also introduced in HEVC. Once the splitting of CU hierarchical tree is done, each leaf CU is further split into one or more prediction units (PUs) according to prediction type and PU partition.
Along with the High Efficiency Video Coding (HEVC) standard development, the development of extensions of HEVC has also started. The HEVC extensions include screen content coding (SCC). Due to specific characteristics of screen contents, coding tools have been developed and demonstrate significant gains in coding efficiency. Among them, the color index coding (a.k.a. major color based coding) techniques represent block of pixels using indices to the palette (major colors), and encode the palette and the indices by exploiting spatial redundancy. While the total number of possible color combinations is huge, the number of colors in an area of picture is usually very limited for typical screen contents. Therefore, the color index coding becomes very effective for screen content materials. Related key color index coding techniques are briefly reviewed as follows.
During the Course of Screen Content Coding (SCC) development, various video coding tools have been described, including the “Intra picture block copy” (IntraBC) technique. The IntraBC technique was first disclosed in JCTVC-M0350 (Budagavi et al., AHG8. Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC 1/SC 29/WG11 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350). An example according to JCTVC-M0350 is shown in FIG. 1, where a current coding unit (CU, 110) is coded using Intra MC (motion compensation). The prediction block (120) is located from the current CU and a displacement vector (112). In this example, the search area is limited to the current CTU (coding tree unit), the left CTU and the left-left CTU. The prediction block is obtained from the already reconstructed region. Then, the displacement vector, also named motion vector (MV) or block vector (BV), and residual for the current CU are coded. It is well known that the HEVC adopts CTU and CU block structure as basic units for coding video data. Each picture is divided into CTUs and each CTU is reclusively divided into CUs. During prediction phase, each CU may be divided into multiple blocks, named prediction units (PUs) for performing prediction process.
In JCTVC-M0350, the IntraBC is different from the motion compensation used for Inter prediction in at least the following areas:                BVs are restricted to be 1-D for IntraBC (i.e., either horizontal or vertical) while Inter prediction uses 2-D motion estimation.        Binarization is fixed length for IntraBC while Inter prediction uses exponential-Golomb.        IntraBC introduces a new syntax element to signal whether the BV is horizontal or vertical.        
Based on JCTVC-M0350, some modifications are disclosed by Pang, et al., in Non-RCE3: Intra Motion Compensation with 2-D MVs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 Jul.-2 Aug. 2013, Document: JCTVC-N0256 (hereinafter JCTVC-N0256). Firstly, the IntraBC is extended to support 2-D MVs, so that both vertical and horizontal MV components can be non-zero at the same time. This provides more flexibility to IntraBC than the original approach, where the MV is restricted to be strictly horizontal or vertical.
In JCTVC-N0256, two BV coding methods are disclosed:                Method 1—Block vector prediction. The left or above BV is selected as the BV predictor and the resulting motion vector difference (BVD) is coded. A flag is used to indicate whether the BVD is zero. When BVD is not zero, exponential-Golomb codes of the 3rd order are used to code the remaining absolute level of the BVD. Another flag is used to code the sign.        Method 2: No block vector prediction. The BV is coded using the exponential-Golomb codes that are used for BVD in HEVC.        
Another difference disclosed in JCTVC-N0256 is that the 2-D IntraBC is further combined with the pipeline friendly approach:                1. No interpolation filters are used.        2. BV search area is restricted. Two cases are disclosed:                    a. Search area is the current CTU and the left CTU or            b. Search area is the current CTU and the rightmost 4 column samples of the left CTU.                        
Among the proposed methods in JCTVC-N0256, the 2-D IntraBC, the removal of interpolation filters, and the search area constraint to the current CTU and the left CTU have been adopted in a draft HEVC SCC standard.
A valid block vector should point to the already reconstructed area of the current picture, and should be outside the current CU. In addition, in SCM-3.0 (Joshi, et al., Screen content coding test model 3 (SCM 3), Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 19th Meeting: Strasbourg, FR, 17-24 Oct. 2014, Document: JCTVC-S1014), a ladder shape IntraBC search range constraint is adopted, as shown in FIG. 2, which is initially intended for Wavefront Parallel processing (WPP). However, it is used for HEVC SCC regardless whether it is for WPP or not. In FIG. 2, each square represents a CTU. For an IntraBC block in current CTU, its available search area is constrained to the dot-filled CTUs and the reconstructed blocks in the current CTU.
Therefore, for a IntraBC coded block, its block vector BV=(BV_x, BV_y) should satisfies the following bitstream conformance conditions:BV_x+nPbSw+xPb−xCb<=0 orBV_y+nPbSh+yPb−yCb<=0  (1)(xPb+BV_x+nPbSw−1)/CtbSize−xCb/CtbSize<=yCb/CtbSize−(yPb+BV_y+nPbSh−1)/CtbSize  (2)
In the above equations, nPbSw and nPbSh are the width and height of the current PU; (xPb, yPb) is the location of the top-left pixel of the current PU relative to the current picture; (xCb, yCb) is the location of the top-left pixel of the current CU relative to the current picture; and CtbSize is the size of the CTU block. When both equations (1) and (2) are satisfied, the reference block pointed by the block vector will be fully within the available search area for the current block.
IntraBC as an Inter Coding Mode
In a recent coding standard meeting, the IntraBC is unified with Inter coding mode (Pang, et al., Non-CE2 Test 1: Intra block copy and inter signalling unification, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 20th Meeting: Geneva, CH, 10-18 Feb. 2015, Document: JCTVC-T0227). In other words, the current picture is treated as a reference picture and inserted into one or both reference picture lists. Block vector prediction and coding are the same as inter motion vector prediction and coding. This unification simplifies the codec design. However, there are some remaining issues. For IntraBC, the block vector has integer resolution. However, the motion vector has both integer and quarter-pel resolutions switched at a slice level. When a block vector is treated at quart-pel resolution, some extra rows and columns of pixels around the block, which is pointed to by this block vector, need to be interpolated. These pixels may not be available in the current IntraBC-Inter unification scheme.
In high level syntax, coded data for the current picture is placed in the bitstream after all short term reference pictures and all other long term reference pictures during the initialization of reference picture list construction. Exemplary pseudo codes for the related reference picture processing are shown below for List 0. At the beginning of the decoding process for each slice, the reference picture lists RefPicList0 and, for B slices, RefPicList1 are derived.
The variable NumRpsCurrTempList0 is set equal to Max(num_ref_idx_10_active_minus1+1, NumPicTotalCurr) and the list RefPicListTemp0 is constructed as shown in Table 1.
TABLE 1rIdx = 0 while( rIdx < NumRpsCurrTempList0 ) { for( i = 0; i < NumPocStCurrBefore && rIdx < NumRpsCurrTempList0; rIdx++, i++ )  RefPicListTemp0[ rIdx ] = RefPicSetStCurrBefore[ i ] for( i = 0; i < NumPocStCurrAfter && rIdx < NumRpsCurrTempList0; rIdx++, i++ )   RefPicListTemp0[ rIdx ] = RefPicSetStCurrAfter[ i ] for( i = 0; i < NumPocLtCurr && rIdx < NumRpsCurrTempList0; rIdx++, i++ )   RefPicListTemp0[ rIdx ] = RefPicSetLtCurr[ i ] if( curr_pic_as_ref_enabled_flag )   RefPicListTemp0[ rIdx++ ] = currPic }
After the initialization, the reference picture list (i.e., RefPicList0) construction is performed in exemplary pseudo codes shown as follows:
for( rIdx = 0; rIdx <= num_ref_idx_l0_active_minus1; rIdx++)  RefPicList0[ rIdx ] = ref_pic_list_modification_flag_l0 ?   RefPicListTemp0[ list_entry_l0[ rIdx ] ] : RefPicListTemp0[ rIdx ]
However, when num_ref_idx_10_active_minus1 is smaller than the index of the entry, in which the RefPicListTemp0 array stores the current picture, the current picture may not be included in the reference picture list. Therefore, it is desirable to develop techniques to overcome these issues.